Mobile IP is a standard that allows users of mobile devices to stay connected when moving from one network to another. In mobile IP, a user's device typically has an IP address associated with a “home” network. When the user leaves the home network and enters the domain of a foreign network, the foreign network uses the Mobile IP protocol to inform the home network of a “care-of” IP address to which all packets destined to the user's IP address should be sent. More particularly, a “foreign agent” (FA) (such as a LAN server or other network access server) in the foreign network may provide a “home agent” (HA) in the home network with the foreign agent's IP address to be used as a care-of address for communications to the device.
Mobile IP is commonly used in wireless packet-data communication systems, such as CDMA2000® for instance. In a CDMA2000® system, mobile nodes (such as cell phones or wirelessly-equipped computers) communicate with radio access networks (RANs), which are coupled via packet data serving nodes (PDSNs) with a packet-switched network. In this arrangement, each of the PDSNs may function as a Mobile IP foreign agent, and a home agent may sit on the packet-switched network to facilitate mobility between the various PDSNs' serving systems. In this scenario, a mobile node is always served by a “foreign agent” PDSN even when the mobile node is operating in its home network.
FIG. 1 depicts conventional operation under CDMA2000®. As shown, at step a, a mobile node would first acquire packet-data connectivity by sending a packet-data origination message into the mobile node's serving RAN. The RAN would then assign an air interface traffic channel for use by the mobile node as a radio link, and the RAN would signal to its PDSN, to trigger establishment of a data link, such as a point-to-point protocol (PPP) session, between the PDSN and the mobile node.
More particularly, at step b, a packet control function (PCF) in the RAN would send to the PDSN over a standard A10/A11 link a Mobile IP Registration Request (MIP RRQ) seeking to set up a bearer path between the PCF and the PDSN, over which the PDSN and mobile node can then engage in negotiation to set up the data link. (FIG. 1 depicts this step as “R-P Interface Setup,” to reflect setup of a radio-packet interface.) This MIP RRQ may conventionally include a “critical vendor specific extension” (CVSE) that provides information about the mobile node, such as the cell/sector currently serving the mobile node, a mobile station identifier (MSID) of the mobile node, an electronic serial number (ESN) of the mobile node, and other information, to enable the PDSN to generate suitable accounting records. After further signaling between the PCF and the PDSN, a bearer channel would then be established, and the PDSN would then negotiate with the mobile node to set up a data link.
Once the PPP session is established at step c, the PDSN, as Mobile IP foreign agent, would then send a Mobile IP Agent Advertisement message to the mobile node at step d, in order to trigger a Mobile IP registration process with the home agent, i.e., to register the PDSN's address as a care-of address with the home agent.
Upon receipt of the Mobile IP Agent Advertisement message, the mobile node would then conventionally send a Mobile IP Registration Request (MIP RRQ) to the foreign agent (PDSN) at step e, providing parameters including (i) user-ID, such as NAI for instance and (ii) the IP address of the mobile node's Home Agent (which may be hard coded into the device). Further, in some implementations, the MIP RRQ may also include an “MN-AAA” parameter, which is an authentication parameter that can be used to facilitate authentication of the mobile node.
When the PDSN receives the MIP RRQ from the mobile node, the PDSN may conventionally initiate an authorization process, by consulting with a server such as a RADIUS AAA server for instance. In an example of this process, the PDSN may send a RADIUS Access Request to the AAA server at steps f and g, providing the user-ID and HA address that the PDSN received in the MIP RRQ from the mobile node. (Further, if provided in the MIP RRQ, the PDSN may also provide the MN-AAA authentication parameter.) In some cases, as shown, this RADIUS Access Request might go to a given AAA server (e.g., a foreign AAA server), which may then proxy it to another AAA server (e.g., a home AAA server), selected based on the user-ID, for handling. The AAA server may then perform an authorization process and provide a positive RADIUS Access Accept message in response to the PDSN, at step h.
Upon successful authorization of the mobile node, the PDSN may then send the MIP RRQ along to the home agent, at step i. The MIP RRQ would usually carry the same parameters as the MIP RRQ that the PDSN received from the mobile node (except that it would not include the MN-AAA parameter if that was provided). The HA may then validate the user internally or perhaps itself query the AAA server (e.g., home AAA server) to validate the user, at step j. The HA may then reply to the PDSN with a Mobile IP Registration Reply (MIP RRP) at step k, providing the home IP address assigned to the mobile node, and including a lifetime for the address. After sending an accounting “START” message to the AAA server for billing purposes, the PDSN may then send the MIP RRP along to the mobile node at step n, providing the mobile node with the assigned home IP address.
Conventionally, the Mobile IP registration process between the mobile node and the home agent is keyed to user-ID (such as an NAI), rather than device-ID (such as MSID, ESN, etc.), so as to enable users to seamlessly access their profile from any device. As a result, the Mobile IP Registration Request to the home agent does not convey a device-ID, and the PDSN and home agent are not arranged to use device-ID in the mobile node registration process as described above.
In some cases, however, it may be worthwhile to report a mobile node's device-ID to a home agent at the time of Mobile IP registration. For example, by collecting device-IDs during mobile IP registrations, a home agent can facilitate centralized fraud detection by checking whether the identified devices were reported stolen. As another example, the home agent could use the device-ID as a basis to verify that the device is a particular type of device; for instance, in a prepaid communication system, the home agent could use the device-ID as a basis to confirm that the device is a “prepaid-device” rather than some other sort of device. And as yet another example, in a prepaid scenario where account balances are keyed to devices (rather than users), the home agent could use the device-ID as a key to monitor an account balance.
On the other hand, it would be undesirable to provide a home agent with a device-ID every time a Mobile IP registration occurs. In many cases, there may be a reason to maintain the device-ID in confidence, and to therefore not reveal the device-ID to the home agent. Further, providing a device-ID to the home agent during every Mobile-IP registration could unnecessarily consume processing power and other resources.